Multimedia broadcast/multicast service (MBMS) is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared.
FIG. 1 illustrates a conventional telecommunications system 100 to facilitate MBMS. The telecommunications system 100 includes a radio access network (RAN) 130. A Broadcast/Multicast Service Center (BM-SC) 110 contains necessary information to control the MBMS in the RAN 130. The BM-SC 110 is connected through a core network (CN) 120 to the RAN 130. The CN 120 can include a Gateway GPRS Support Node (GGSN) and, in some implementations, a Serving GSN (SGSN) node connected between the GGSN and the RAN 130. Alternatively, in the case of a “one tunnel” implementation, the user plane might not go via SGSN but the control plane always does.
The RAN 130, an example being a Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN), includes a radio network controller (RNC) 140 and at least one radio base station 150, also known as a “Node-B” or “B Node”. The Node-B 150 can serve one or more cells such as cells C1 through C3 illustrated in FIG. 1. That is, the Node-B 150 provides MBMS data to one or more user equipments (UEs) 160, also known as mobile stations or mobile terminals, which communicate with the Node-B 150 over a radio (or air) interface in the respective cells.
The MBMS utilizes several types of data transport bearers. A MBMS Iu data bearer is a data bearer established to transport the MBMS data from the CN 120 (such as a SGSN node or GGSN) to the RNC 140. A MBMS radio bearer is a data bearer established to transport the MBMS data from the RNC 140 and the UEs 160 via the Node-B 150. The term MBMS RAB refers both to the MBMS Iu data bearer and the MBMS radio bearer.
A MBMS session uses several channels, including: MCCH (MBMS point-to-multipoint Control Channel); MICH (MBMS Notification Indicator Channel); MSCH (MBMS point-to-multipoint Scheduling Channel); and MTCH (MBMS point-to-multipoint Traffic Channel). FIG. 1 shows the MTCHs 155-1, 155-2 and 155-3 (collectively MTCHs 155) between the Node-B 150 corresponding to cells C1, C2 and C3, respectively, served by the Node-B 150. The Node-B 150 delivers the MBMS data to the UEs 160 in the cells using the MTCHs 155 corresponding to each of the cells.
FIG. 1 also shows Iub bearers 145-1, 145-2 and 145-3 (collectively Iub bearers 145), over an Iub interface, i.e., over an interface between the RNC 140 and the Node-B 150. In FIG. 1, the MTCHs 155-1, 155-2 and 155-3 respectively correspond to the Iub bearers 145-1, 145-2 and 145-3. That is, the MBMS data transported over the Iub bearer 145-1 to the Node-B 150 is retransmitted to the UE 160-1 over the MTCH 155-1 corresponding to cell C 1 by the Node-B 150. In a similar manner, the MBMS data is transmitted over the Iub bearers 145-2 and 145-3 and retransmitted over the MTCHs 155-2 and 155-3. A forward access channel (FACH) transport channel mechanism is used over the radio interface for each of the Iub bearers 145.
A MBMS session is started with a MBMS Session Start Request message sent from the CN 120 to the RNC 140. The MBMS Session Start Request message includes such information as a MBMS Service ID, a MBMS Bearer Service Type and MBMS Session Attributes. The MBMS Session Start Request message triggers the RNC 140 to notify the UEs 160-1, 160-2, 160-3 and 160-4 (collectively UEs 160) regarding the MBMS Session Start. The MBMS Session Start Request message contains the information necessary to setup (i.e., “configure”) the MBMS RAB.
In UTRAN, upon receiving the MBMS Session Start Request message, the RNC 140 performs numerous activities, including execution of a Node-B Application Part (NBAP) protocol. The NBAP protocol provides, among other functions, a Common Transport Channel Management function. This function gives the CRNC (e.g., the RNC 140 in the illustrated scenario) the possibility to manage the configuration of the common transport channels in the Node-B 150. Elementary procedures controlled by the Common Transport Channel Management function include a Common Transport Channel Setup Procedure; a Common Transport Channel Reconfiguration Procedure, and a Common Transport Channel Deletion Procedure.
The Common Transport Channel Setup Procedure is described, e.g., 3GPP TS 25.433 V7.1.0 §8.2.1. The Common Transport Channel Setup Procedure is used for establishing the necessary resources in Node-B, regarding Secondary CCPCH, PICH, PRACH, AICH [FDD], FACH, PCH, RACH and FPACH [1.28 Mcps TDD]. Messages in the Common Transport Channel Setup Procedure include: COMMON TRANSPORT CHANNEL SETUP REQUEST message; COMMON TRANSPORT CHANNEL SETUP RESPONSE message; and COMMON TRANSPORT CHANNEL SETUP FAILURE message. The Common Transport Channel Setup Procedure is initiated with the COMMON TRANSPORT CHANNEL SETUP REQUEST message sent from the RNC 140 to the Node-B 150.
The COMMON TRANSPORT CHANNEL SETUP REQUEST message is described, e.g., in §9.1.3 of 3GPP TS 25.433 V7.1.0 (2006-06). If the COMMON TRANSPORT CHANNEL SETUP REQUEST message contains a FACH Parameters IE, the Node-B 150 configures and activates the indicated FACH(s) according to the COMMON TRANSPORT CHANNEL SETUP REQUEST message. If the COMMON TRANSPORT CHANNEL SETUP REQUEST message includes the Transport Layer Address and Binding ID IEs, the Node-B 150 may use the transport layer address and the binding identifier received from the RNC 140 when establishing a transport bearer for the indicated common transport channels.
After successfully configuring the requested common transport channels and the common physical channels, the Node-B 150 stores the value of Configuration Generation ID IE and responds with the COMMON TRANSPORT CHANNEL SETUP RESPONSE message with the Common Transport Channel ID IE, the Binding ID IE and the Transport Layer Address IE for the configured common transport channels.
In the conventional telecommunications system such as the one illustrated in FIG. 1, a separate Common Transport Channel Setup Procedure is required to establish the MTCH 155-1, 155-2 and 155-3, respectively, for each cell C1, C2 and C3. If the MTCHs 155 are to be established in the three cells C1, C2 and C3 served by the same Node-B 150, then three separate Common Transport Channel Setup Request messages are initiated by the RNC 140, one message for each cell.
FIG. 1 shows that there are three transport bearers 145-1, 145-2 and 145-3 (collectively transport bearers 145), one for each cell, between the RNC 140 and the Node-B 150. These transport bearers 145, also referred to as the MBMS Iub bearers, respectively correspond to the three MTCHs 155. 3GPP TS 25.402 describes the frame timing calculation principles in cases where cell specific transport bearers are used for broadcast/multicast channels.
In the conventional system, a separate transport bearer to transmit the MBMS data from the RNC 140 to the Node-B 150 is configured for each MTCH 155 used to transmit the same MBMS data from the Node-B 150 to the UEs 160 in the respective cells C1, C2 and C3. Allocating separate transport bearers, one for each cell, creates inefficiencies since the same MBMS data are replicated over multiple transport bearers. What is needed is one or more methods, techniques, and/or apparatus for efficiently providing MBMS user data transport to a Node-B which serves plural cells.